有沒有一種可能…不是 Vue 很慢，而是自己根本不知道到底哪裡慢？🤔

「首頁怎麼又變慢了？」

這句話，大概是我從前公司到現在只要遇到大型 Vue 專案最常聽到的一句話！

每次聽到，前端們都會很有默契自動打開 DevTools 開始我們的表演！

A：是不是 API 太慢？可是 API 都在 200ms 內。
B：圖片是不是太大，那個誰誰誰你有先跑貓熊 TinyPNG 腳本嗎？
C：Vue Render 太慢？Pinia 又跑初始化？
D：Router？啊！會不會 MIS/IT 又忘記初一、十五放新的乖乖？
E：最近新加的那個 Component 拖累速度？
F：要不要補個 keep-alive？

討論了一整個下午，最後，每個人都有自己的答案，但沒有一個人能證明自己是對的，最後都是由專案負責人決定對外統一說法。

後來發現，很多大型 Vue 專案真正的問題，不是效能不好，很有可能是 我們不知道真正的瓶頸在哪裡。

後來我開始重新看這些問題

回頭想想，工作上遇到的效能問題，好像都有類似的模式。

有時候是首頁 Loading，有時候是大量資料開始卡，也有時候是 SPA 開久了之後，整個系統慢慢變得奇怪，這些問題表面上反饋就是「很慢！」

xxx 很慢 → 第一個想到 API → API 沒問題 → 開始懷疑 Vue → Vue 好像也沒有證據 → 最後只好開始到處找原因 → 負責人說句話 → 結束！！！

是不是很熟悉？從轉職到現在的公司似乎這套流程都會走一遭！其實，猜對猜錯天知道，因為當下也 沒有一套方法可以驗證？

所以，在開始寫 Vue 3.6 之前想先整理過去經歷的 大型 Vue 專案，到底有哪些「值得驗證」的問題？

專案的痛點

這幾年參與大型專案都會「反覆」遇到的情況，重點是不同性質的專案也會出現雷同的問題。

1. 首頁 Loading 很慢

登入後打開首頁，畫面其實已經出現了，但是 Banner 還在 Skeleton，推薦商品還沒出現，使用者資訊還在初始化，甚至連公告跑馬燈還沒載入，整個首頁像是在「慢慢長出來」！

有趣的是，只要拜託後端幫忙提升 API 回傳速度，後端通常會說：「你要確耶！API 都很正常啊！」

沒錯！但 API 正常，不代表使用者看到畫面的成本正常。 當然這句話說出來傷感情，只能打碎往肚裡吞！只好默默回去想：那到底慢在哪？是 Vue？還是整個初始化流程？

這是第一個值得驗證的問題。

2. 資料一多，畫面開始卡

後台管理系統更常遇到這種情況！

一開始只有幾十筆資料，什麼都很順，直到某一天 PM 說：「可以一次查一年嗎？不行的話，季也可以！」結果變成：

3,000 rows
×
20+ columns
×
Search / Sort / Filter

接著開始出現前端最不想面對的，滑動掉幀 → 操作延遲 → 切頁卡頓！

這時候，大家第一個反應就是後端回來太慢，當後端說已經很快的時候，前端就會反應 Vue 不夠快！？ 哈！沒辦法，總是要給老闆一個理由！

但是知道的人就是知道，這句話其實太早下定論！因為真正的成本可能來自：

Reactive Update
      ↓
Render / Patch
      ↓
DOM
      ↓
Layout / Paint

到底哪一層是問題所在？沒有量測之前，其實不知道。

3. 一個 Input，背後可能是一條 Reactive Chain

大型系統很常見使用者在輸入框操作，結果 F12 Console 一直跳 warning，因為背後可能有很多事情同時發生導致 Slow。

const keyword = ref('')
watch(keyword, () => search())
watch(keyword, () => validate())
watch(keyword, () => analytics())
watch(keyword, () => saveHistory())

想想，今天只有 4 個 watch()，好像沒什麼！

如果專案持續演進，如果 AI 幫你寫出了 40 個呢？是不是每打一個字，都可能觸發一連串 Reactive 更新？

所以丟掉 watch()？ 這過於偏激，或許我們可以換個方向想一下：一次使用者操作，究竟觸發了多少工作？

4. 點一下選單，畫面為什麼停住？

相信不少 SPA 都遇過，點一下選單，畫面停住，過 1 秒才出來，這 1 秒到底發生了什麼？

Click
 │
 ├─ Component Mount
 ├─ Store Init
 ├─ Composable
 ├─ Reactive Effects
 ├─ Render
 ├─ DOM
 └─ Browser Rendering
 │
 ▼
「這一秒到底花在哪？」

如果沒有量測或是依據，每個人都可以提出自己的猜測，但是真的是這樣嗎？

5. Component 越拆越多，真的比較好嗎？

還記得剛開始的首頁 HomePage.vue 嗎？本來只有單純的幾個組件，因應商業需求，半年後繁衍超快，不過都是過去式了，現在有 AI 只要幾秒鐘要多少有多少，不用等半年！

HomePage
├── Header
├── Banner
├── Notice
├── Promotion
├── GameList
│   ├── Card
│   ├── Badge
│   ├── Button
│   └── Favorite
└── ...

上面的專案架構還只是一個 HomePage 就把 Component 拆的很細，看起來好像乾淨而且擺放整齊，但是 Props 越傳越深，Component Tree 越來越複雜，最後讓人感到可怕的是不知道誰傳誰！

所以不要怪前端怎麼常常對著螢幕自言自語，因為慢就算了，還不知道這筆資料到底來自何處？這也是大型專案常見的技術債。

6. Composable 越拆越多，也可能變成另一種成本

Composition API 給了我們很大的自由，但是自由也代表 什麼都可以拆。 最後很容易變成：

useUser()
   ↓
usePermission()
   ↓
useRole()
   ↓
useConfig()
   ↓
useAPI()

每個 Composable 都有自己的 State，每個 Composable 都可能建立自己的 Effect，程式沒有錯，畫面都正常，只是越來越難理解。

7. SPA 為什麼開越久越慢？

這個經驗，我相信很多人都有！早上登入很順，下午開始覺得怪怪的，F5 又恢復正常。

到底是為什麼？前公司最常用的理由是：資料庫排程更新！哈！因為不知道，所以這時候什麼都有可能，反正有人信就好！

Memory？
   ↓
Effect？
   ↓
Cache？
   ↓
Watcher？
   ↓
Component？
   ↓
Browser？

這時候，我才發現一件很重要的事

整理完之後，我突然發現以前習慣性把所有效能問題都怪給 Vue，但是現在回頭跟 AI 一起看，它們其實至少分成三種不同的成本。

Runtime Cost

這才是 Vue Runtime 真正需要回答的問題：

Reactive Update 到底花多少？

Render / Patch 到底花多少？

Framework 本身到底付出多少成本？

這些才是可以透過 Benchmark 與 Trace 去驗證的東西。

Architecture Cost

如果 Component 已經失控、Composable 到處互相依賴、Data Flow 沒有 Boundary，就算 Framework 再快，也不代表系統會變得容易維護。

以前我甚至遇過一個超大型後台專案，專案負責人直接規定：

1. Component 最多只能往下 4 層。
2. 本專案拒絕使用 Provide/ Inject。

原因都是在避免資料傳到最後沒有人知道從哪裡來，當然這種規則不一定適合每個專案，但它提醒了我一件事 有些問題，本來就不是 Runtime 能解決的。

AI Amplification Risk

今年，我又多看到了一個以前沒有這麼明顯的問題 AI Coding。

AI 可以很快幫我們產生：

更多 Component
更多 watch()
更多 computed()
更多 composable
更多 state

它不一定創造新的問題，但它可能讓原本很小的問題，快速變成大型系統的問題，所以這一系列不只要針對痛點確認 Vue 3.6 能幫我解決多少困擾？同時，當 AI 開始大量寫 Vue，我們到底該怎麼控制系統的成本？

讓我們一起理性面對

我會把工作中遇到的問題，一個一個抽象成可以重複執行的 Scenario，建立一個公開的 Vue Runtime Lab。

從下一篇開始，我們關心層面從 Vue 版更前後的快慢，昇華到根本原因，從頭開始規劃量測 這個成本，到底發生在哪一層？

這會是接下來整個 30 Days Validation Lab 的起點。